Pipeline 是一個自動化的管線運輸貨物方式。從撰寫程式開始到程式上線，中間經過的流程通常都會是固定的，因此我們或許也可以把程式看成是貨物，使用 Pipeline 的概念將各階段的自動化處理整合起來。程式的修改只要有觸發，都可以啟動自動化處理，讓修改的過程成為一個「程式流」。

這個主題跟昨天的 Build Script 互有關係。昨天先定義好各階段的自動化，今天是在定義「前一階段的結果送交給下一階段開始處理」的自動化，有點類似 Kanban 的「從 Done 到 Doing 」的自動化。

以下繼續由昨天的例子延伸來討論：

Development

開發階段可以做的觸發與自動化非常多樣化，比方前端最常使用的 gulp watch ，或是 watch 配合 codeception ，當有修改就做單元測試；而在提交版控前，可以掛上 hook ，讓提交程式之前，會做一些必要的測試和基本的檢查，比方說較快的整合測試和 Coding Style 檢查。這些都是可以由開發者人員由搭配使用的，也因此套件管理系統通常也會定義一個區塊的套件是開發用，另一個是上線用，為的就是讓開發人員方便開發。

但不管怎麼調整，開發人員的任務是寫出「可用的程式碼」，而可用的定義是指上述測試通過。當然也是可以定義人工 UI 測試成功即表示程式是可用的，但測試範圍（即成本）跟品質是有直接相關的，這是管理人員該考慮是否要投入成本。

Testing

理論上當開發人員提交程式的時候就可以開測了，只是看要完整的含人工測試，還是自動化測試跑一跑就好。通常版控系統都會有收到 push 的 hook 可以掛到 CI server 上，而 CI server 收到開發人員完成程式的通知時，會去抓最新的程式碼並做自動化測試與產生報表等。

自動化測試執行完畢後，錯誤的話， CI Server 會記錄並通知開發人員。正確的話可以看下一步流程。如果有執行 code review 的話，開發人員可以在覺得可行的時候手動發 PR 給 reviewer 。當 reviewer 覺得沒問題，可以佈署預發佈環境時，就能按下 Accept 了。

Deployment

按下 Accept 時，可以再接 PR hook 給 CI server ，讓 CI server 知道這次是要玩真的了。 CI server 這時除了上述測試外，也需要產生一包發佈用檔案，並標記這些檔案的版本資訊等。有了發佈用檔案後， CI server 就能進一步佈署到預發佈環境。

這時就能做更多測試，如滲透測試、效能測試、可用性測試、 E2E 測試，等等。等所有測試與檢查都完成後，這一包發佈用的檔案，就是一份可以正式上線的程式了。

Artifacts

注意裡面有些流程會有產生一些非原始碼的檔案，如編譯過的檔案或報表等，這些檔案通常稱為 Artifacts 。它們不需要被版控系統所控制，因為原始碼就能產生一樣檔案，但它們應該需要保留起來，並公開這些資訊給團隊成員，這也算資訊透明化的一部分。

另外編譯過的檔案，通常會是發佈時才需要保存和記錄版號。除了可以 rollback 外，如果其他團隊只需要結果（如用 Go 寫了一個小工具）而不需要參與開發時，這些資訊有公開就會令大家非常開心，合作上也會減少更多阻礙。

今日回顧

一個階段完後，參考結果再決定下一個階段如何開始，這樣就是一個簡單的 Pipeline 的概念。

開發人員提交了一包原始碼後，每過了一個階段，這包原始碼感覺就越沒問題。到了最後一步準備要 Deploy 前，相信大家都對這包發佈用的檔案是極有信心的，而不會再是「上線即祈禱」了。

相關連結

• Pipeline | 維基百科